Fixes #5599

• Supports Az Function .net 4.6 and adopt tests accordingly. Update: target of version 1.x -> Not supported.
• ILogger as static field. Update: Only needed if catch block is outside of entry point. Update: instance field used in the DI samples
• Is Ilogger optional in an Azure function? If yes, check the presence. Update: It's optional, so check the presence. Update: Done in 4876dcf
• What about TraceWriter in version 1.x Update: target of version 1.x -> Not supported.
• What about try/catch outside the annotated entry point
• What about DI containers
• Should we respect Disable?
• Offer code-fix?
• calls on custom extension methods (e.g. for the exception filter case)
• ILogger via constructor injection https://docs.microsoft.com/en-us/azure/azure-functions/functions-dotnet-dependency-injection#iloggert-and-iloggerfactory
• generic ILogger<T> (see example above)
• What about telemetry client as an alternative way of logging?
• What about other logging libraries (e.g. Serilog) Rule S6423: Always log failures in Azure Functions #5645 (comment)
• The rule makes sense for every catch block and is not just related to AzureFunctions. Should we remove the AzureFunction requirement?
• FP: A caught OperationCancelledException does not need to be logged
• FP: A throw statement in a catch clause is delegating the logging to the next level. No need to log the exception twice.

Azure functions entry points: https://docs.microsoft.com/en-us/azure/azure-functions/functions-dotnet-class-library?tabs=v2%2Ccmd#methods-recognized-as-functions